fix: report the installed version for go install builds - #6

Found while verifying that the GitHub Action can install the linter from the private repo: the install worked, but the binary reported the wrong version.

$ go install github.com/DivergentCodes/commitlint@v1.1.1
$ commitlint version
0.0.0-dev          # <- should be v1.1.1

version is only ever set by the release workflow's -ldflags. Every other build leaves it at the default — including go install ...@vX.Y.Z, the install path the README documents and the one the GitHub Action uses. So release archives reported correctly and the common case didn't.

Fix

The toolchain already records the module version in the binary:

$ go version -m commitlint
  mod  github.com/DivergentCodes/commitlint  v1.1.1  h1:uqR3um9k4YYQvrJHdq9n4M8sC/Ys+fHpL66qpNozWBY=

That's exactly what debug.ReadBuildInfo() returns as info.Main.Version, so read it back when the ldflags stamp is absent. Precedence: stamp → build info → default.

(devel), which a local go build records, is suppressed in favor of 0.0.0-dev — it's less informative, not more.

Verification

• ldflags path: -X main.version=v9.9.9 → reports v9.9.9 (release archives unaffected)
• local build: reports 0.0.0-dev, not (devel)
• go install path: confirmed via go version -m that Go embeds mod ... v1.1.1 in the installed binary — the exact field the fallback reads
• go vet, go test -race ./... clean

Note the added test pins precedence and the no-(devel)/no-empty guarantee, but cannot assert the installed-version path directly: under go test the module version is always (devel). The go version -m output above is the real evidence for that path, and the test comment says so rather than implying more coverage than exists.

Zero third-party dependencies preserved (runtime/debug is stdlib).

🤖 Generated with Claude Code

https://claude.ai/code/session_01VSrrciEDBTuFNMtKocScML